Please note that the answer to question 1 above only refers to URLs to other databases, not the current database! The ICM was designed on the referral model. The original URL that the end user uses in their browser (and which should be their favorite or bookmark) is the URL of the ICM. After the ICM refers the browser to the most appropriate server, all URLs generated in that session are server specific.
This works very well for performance of the ICM since it is involved only during the initial connection. But it only works well for failover if the browser never saves any of those intermediate URLs and only if the end user uses the original favorite or bookmarked URL when a server fails.
This is an inherrent problem of the use of the referral model. We're sorry if this is not meeting your needs.
However, you didn't include sufficient information in your post to offer other solutions. If all or a subset of the databases being served by your site have replicas on all or a subset of the servers in your cluster, a better solution would be a network sprayer configured with connection stickyness. In such a configuration the network sprayer could select any server in the server group for the IP address or URL entered and the request would be honored. Since this does not involve referral, the end user never sees any of the names or IP addresses of the specific servers and failover among the servers is transparent (as long as authentication supports LTPA)
This solution solves the referral problems but it does not by default know the load on any of the servers. The sprayer can be configured to work on active - passive mode or can be configured to distribute connections evenly across servers. If the servers are matched in power and carry the same general load, this even distribution of connections works very well. If you really need however to distribute connections based on load, some network sprayers offer apis to allow customers to determine which server to connect to. It is possible to consider writing code for a sprayer that interrogates Domino servers to determine their load and which server has a replica. This solution would provide all the power of the ICM with none of the disadvantages.